Summary

This PR fixes a false positive in the release workflow where versions were incorrectly marked as "already released" when they were never published to crates.io.

Problem

The release workflow checked if a git tag exists to determine if a version was already released:

if git rev-parse "v$CURRENT_VERSION" >/dev/null 2>&1; then
    echo "... already released"
fi

This caused false positives because:

1. Git tags can exist without the package being published to crates.io
2. GitHub releases create tags but don't publish to crates.io
3. The package browser-commander has 10 GitHub releases (v0.1.1 - v0.5.4) but NONE on crates.io

Solution

Changed the version check to query crates.io API directly:

CRATES_IO_RESPONSE=$(curl -s "https://crates.io/api/v1/crates/${CRATE_NAME}/${CURRENT_VERSION}")
if echo "$CRATES_IO_RESPONSE" | grep -q '"version"'; then
    VERSION_ON_CRATES_IO=true
fi

This ensures we only skip releases when the version is actually published on crates.io.

Changes

• .github/workflows/rust.yml: Updated version check logic to query crates.io API
• docs/case-studies/issue-29/: Added comprehensive case study documentation including:
  • Timeline of events
  • Root cause analysis
  • CI run logs and metadata (from run #21092316062)
  • Proposed solutions

Test Plan

• Tested crates.io API locally - correctly returns "not found" for browser-commander
• Tested crates.io API with existing crate (serde) - correctly detects published versions
• Verified grep patterns correctly extract crate name and version from Cargo.toml

References

• Issue: Release failed, because version check got false positive #29
• Failed CI Run: https://github.com/link-foundation/browser-commander/actions/runs/21092316062/job/60665291821
• crates.io API docs: https://crates.io/api/v1/crates/{crate_name}/{version}

Fixes #29

🤖 Generated with Claude Code